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For the past several years, efforts have been unagerway fo rewrite 
ana. generally clean up the coae in the tools which are used to 


maintain the Multics System Libraries. A major phase of the 
effort ended with the installation of fne update_seg command, 
whicn instalis segments in the Online Libraries. Now a second 


major phase is coming to fruition. This MTB Summarizes fhe work 
which was gone as part of this second phase. 


Sinc2 the work was begun before MTBsS or the MCR board came into 
peings if has been proceeding without having an approveo MCR. It 
is ny intention now to hold a Design Review of the basic designs 
summarized below, and then to submit several MCRS requesting the 
installation of tne new or modifies iibrary tools. 


Goais of Phase Ino 


Phas2 Two of the clean up campaign aadresses {at least) 7 
different toois which are used in Jibrary maintenance. These 
are? msi_info3 msi_globai_format; ms!_short_tformat 3; 
get_iibrary_source 3 cleanup; icref; and cross_reference. 
Respectively, these tools: printed brief information about 
entries in the tibrary on the user's terminal; generated 
detailed jibrary status information in a segment$ generated 
brief jiibrary status information in a segment; extracted source 
segments from the jibrary3; actually delete from tne Online 
Libraries those segments which were replaced as part of an 
installations but which could not be celetea at instaliation time 
because they might have been in use in someone*s process; 
cross-reference the use of include segments by fibrary entries} 
cross-reference the use of library entries oby other liorary 
entries. (1) 
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(14) 2ast tense is usea in some of the descriptions above to 
ingicate a change in the operation of certain fools. For 
example, we no longer have MSLs (Multics Segment Lists), $0 the 
mst programs have been replaced by three new programs which 
perform the same function in a different way. These programs are 
aescribea in a forthcoming MT3. When the Ontine Libraries were 


Multics Project internal working documentatione Not to be 
reproduced or distributed outside the Multfics Project. 
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Each of these tools has one or both of the following design 
flaws: 


* eifner the tooi usea a speciai iibrary dafa DaSe whnicn 
was Invariably out-ofesync with the actual library 
contents (the MSL data base); or 

* both the togical ana physical organization of the 
Multics System Libraries is coded into fhe tool ans 
therefore the tool nas to be modified whenever’ the 
fjogical or physical organization changes in any waye 


Therefore, the goals of the clean up campaign are to: 


++ eliminate the information from the MSLS which is 
cupticatec elsewhere in the tibraries (e.ge, status 
information for library entries, name of bound segment 
containing a component, language type of a component) 
ana to store the remaining information in a cata base 
which is Simpler to maintain, easier to check for 
consistency, and which does not interact with the 
fibrary installation toois$; ana 

++ store the organization of the Multics System Libraries 
(the airectory structure, naming conventions, and 
kKnowlecge of the types of segments in particular 
directories) in a single data base which can be used by 
each tool,» and which can be centrally updated when 
reorganizations occur. 


Reoiacing the MSL 


It has been fairly easy to meet the first goal stated above, 
because the only MSL information not contalned elsewhere in the 
libraries (either as segment status information or as archive 
component header informstion) is the ID of the particular system 
in wnich a Hardcore or Satvager Library entry was fast modified. 
However, there is a airect relationship between tne date on which 
a fiborary entry was fast modified, and tne date on which a 
particular system was Installed in the tibraries. Therefore, we 
can replace the MSL data bases with &@ much simpler data base 
consisting of a tist of system IDs for Hardcore and Salvager 
SystemSy and the daate on which those systems were installea in 
tne tibraries. Then»s Dy comparing the date modified of each 
Hardcore or Salvager Library entry with this JiSt, we can 
oetermine in which system the entry was ftast mocified. 


The tist of system IDs is implemented as an array of system ID = 
Gate pairs, sortea by date (and therefore by system IO too). New 
re-organized, get_library_source Was extended to allow extraction 
of object segments from the Online Libraries anda was therefore 
renamed get_library_segment. 
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commanas add an entry to the bottom of the fist each time a 
Hardcore or Salvager system is updated into the fiorariess, and 
replace or defete entries which are in error. When given s date 
fast modified for a tibrary entrys a new subroutine returns’ the 
appropriate system [D. : 


Note that the tist is easy fo maintain and to check for 
consistency, ana that it does not interact with the Hardcore 
upaater, but is upcatec insteaa (via commana) by the installer at 
the end of the Hardcore or Salvager installation process. 


Having repiaced the MSL with the system ID list, it nas also been 
necessary to reptace the mst tools whicn reporteda on the 
Information stored in the MSLse msi_info will be replaced by 
fibrary_info (cocing is in progress), ana msi_short_format and 
msl_global_format have been replaced by library_map. Tnese new 
tools will be described in a forthcoming MTB. 


Proplem With Library Organization 


One of the biggest probiems confronting the tibdrary maintenance 
tools is the organization of the tfibraries tnemselves. For 
various reasons, the system is divided into different logical 
libraries, and these tibraries are in turn  diviaea into 
Sub-flibraries (or directories). Thus, we have the stanoard 
jibrarys, unbundied tibrary,s tools tibrary,s author-maintained 
{ibrarys, instaltlation-maintaineo tibrary, network Iibrarys eee. 
And we have, wifhin each Jtlivrary, source directories, object 
directories, bind tist directories, execution airectories (those 
seen by the user)s+s bound component sirectories, info directories, 
include director ieS, eees 


Even more of a problem than the ever protiferating number of 


logical fibraries is the mapping of these fogical entities onto 
tne physical directories of the Mulitics Storage System. Ada to 
these the different naming conventions used in <daifferent 


libraries, the differing search procedures, the restrictions on 
the types of entries olacedad in libraries, etc and you nave an 
almost unmanageable set of rules for maintaining ana accessing 


entries in the libraries. Implementing reasonably efficient 
Search procedures which can treat all of tne tibraries in a 
fairly uniform manner is an extremely difficult task. 
Implementing such procedures in each of tne many lidrary 


maintenance tools woula be impossible. 


The evidence in the paragraph above fled directiy to the 
conclusions? That the tibraries must have the Simplest 
organization possible while providing reasonable storage and 
access efficiency; that. all libraries should have the same 
orgarizations if possible; and that the proceaures for 
maintaining and accessing entries in the tibraries should be 
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common to all library maintenance toois, and Shoula be centrally 
located in a single external module which can be easily modified. 


Acting on these conciusionsSs in 1971 we bpegan tne process of 
reorganizing the Jibraries, starting with the Online Libraries 
(the targest). The new ftibrary organization was chosen for its 
efficient storage of entries, its ease ana efficiency of access 
to entries, and its simplicity. (2) 


It is our goal (though a distant one) to promuigate this new 
organization throughout sil of tne Multics System Libraries. The 
biggest barrier to a uniform tibrary organization are _ the 
Harecore ana Saivager Librariless which are currentiy organizea in 
a manner to optimize the installation of large groups of 
modifications (new systems) at one times rather than to promote 
ease ana efficiency of access to entries and simplicity of 
orgarxizatione 


Tnus», there are currently two different organizations usea in the 
Muitics system  Lioraries, and we are tikely to retain thnese fwo 
organizations for the foreseeable futuree 


Centralizing LiObcary Organization Information 


Having Gecided to centralize the kKnowlecge of library 
orgarization into a single module, we first nad to decide what 
knowledge was needede The list below outlines the information 
whicn is currently bdeing storedcs or is Known to be needea in the 
near future for proposed extensions to Jtibrary mairtenance 
commandSe 


Ae the logical structure of the fibraries, incluaing 
library names, directory nameS, ana the relationship 
between the various agirectories of a given !tibrary. 


Be the mapping of this logical structure onto the physical 
directories of the Multics Storage System. 

Ce the conventions for separating the various types of 
library entries among the directories of a given 
library (@eges, Source segments go In the source 


airectorys info segments go in the info airectory of a 
fiorary, efc). 

De the conventions for storing the various types of 
fibrary entries in the tibrary directories, and for 
naming those stored entries (@ege5 the source for bound 
segments is stored in a Source archive, the archive is 
nameag bounu_seg name_e«Searchives, anu has adaitfional 
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(2) The new library organization is described in MSB-87, “Plan 
for Multics System Library Conversion ana for Shifting Library 
Maintenance to the 6186". 
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Names for each of the source components it contains). 


a the conventions for accessing Jibrary entries in 
fibraries with differing organizations. 

Fe the attribufes of new entries piacea in a iibrary 
(Esges ACLs ring brackets, AIM Controls, etc). 

Ge the type of information which should be reaturneds, by 


aqefault, for the entries of various tibraries (ee ge, in 
the Online Libraries, ring brackets are important 3 
they are not in the Hardcore Libraries). 

He the conventions for modifying ana deteting tibrary 
entries as part of the normal installation process. 


Tne next step was to decise in what form to store this highly 
variea set of. information. While some of the information is 
Simple in nature and can easily be tabularized in some data 
structure, much of the information is too compiex to be uvescribed 
by ayy data base generation language, or even to be stored in 2a 
general data base structure. Tnerefore, the information was 
split into two parts: that which coulda be tabuiarized in a aata 
pase; ana that which nad to be encoded into 3 program. A new 
data base and program were then created, along with a simple 
compiler for the aata base. The aata base is known as the 
fiorary aGescriptor, and the program is called the tibrary search 
programe 


Ihe Wibrary Descriptor 
Currenttys the tibrary aescriptor contains: 


1s a definition of the roots of the tinrary, the parts of 
the fidrary which remain constant across modifications 
made to the tibrary, and from which a searcn can pegin 
for library entries. 

Ze the names by which each Jlibdrary root can be referenced. 

36 the relationsnip between a library and its 
sub-libraries, as expressed by Common name components 
(e@egee the tibraries stanaara.source, standard.object, 
and standarc.lists share a name component, and are 
Therefore related; Similarly, Standard.source, 
unbunclea.source, toolsesource, ang autn_maint.source 
share a name component and are relatea). 

be the path name of the physical directory (3) which is 
The realization of the togical library root in the 
Multics Storage System. 
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(3) An archive may silso be a tibrary root, with its components: 
being the library entries. For example, the bind_maps.earchive of 
the Hardcore ana Salvager tJlibraries is a tibdbrary root which 
contains, aS arcnive components, the bind Jlistings for the 
Hardcore Library dound segments. 
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De an entry variable which aefines the entry point in tha 
library search program to be called to search for 
entries in the library roote 


Future plans call for associating fhe following adaitional 
- information with each tibrary root: 


Ge the ACL, ring brackets, and AIM contro!s which are used 
by default when installing new entries in the tiorary 
roote 

fe a list of suffixes which define, through naming 
conventions, the types of entries which may be 
instattles in the liorary root (eeges a source tiodrary 


root can contain onty **.Searchives, *2«dli, *.atm, 
*.,fortran, *.DCpl, Fee weeds 

Be an entry variable which cefines the entry point in a 
fibrary installation program to be called to install an 
entry in the library root. 


In aucition, the library aescriptor aefines the default liorary 
names anc search names which are to be used with each of the 
f{ibrary maintenance commandse These oefault values must be 
specifiec in the tibrary descriptor, because they depend upon the 
names of the tibraries defined in the descriptor, ana on the 
naming conventions usec for entries in the iiorarye For each 
library maintenance Command which uses’ fhe fibraty descriptor, 
tne following information is stored? 


9. a switch inaicating whether or not the command is 
Supportea by the library descriptor and tibrary search 
programe 


an array of default tibrary names (whicn may be empty). 
an array of aefault search names (names used to search 
for tibrary entriess this array may also be empty). 


| a * 
rec) 
e * 


A simple aata base language was developed to define the contents 
of 6 liorary sescriptor. Definitions written in this  tanguage 
37e storea in tidrary sescriptor source segments, whicn have a 
name suffix of .fa;s they are compiled into an ALM data segment 
oy the fiorary_cescriptor_compilter . (ldc), 3a 
reaguction_compiler-generatea compiter. 


Atl references to Jlivorary descriptors are maae through 3 
subroutine callecac tib_descriptor_, wnicn is responsindle § for 
maintaining a constant user interface to the Intormation across 
changes in the irternal structure of the Gata. 
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Ihe Library Search Program 


The tibrary search program contains one entry point for each 
class of tidrary roof. Livdrary roots are ciassified according fo 
tne following criteria’ 


Se the kind of entries stored in the library root (e@eGes 
source entries, or info entries, or executable entries, 
etc). 

Dis the type of entries stored in the tibrary root (eeges 
linkss segments, Girectories, archives, MSFs). 

Ce the naming convention used in the Library root, and the 
associated procedure for searching for library entries. 

ie the way in which moagifications are installed into the 


roots and the mechanism for flagging obsolete entries 
awaiting aeletion. 

Ce the type of status information which shoulda be returned 
by oefault for the various types of library entries in 
the root... 

f. the depth in fhe tibrary hierarcny (of directories, 
archives and MSFs) at which searching for a library 
entry celow the root should be aiscontinuad. 


Each entry point in fhe fibrary search program performs” the 
searching functions for the various ftiorary maintenance commands 
accorcing to the criteria appropriate to one library root classe 
Tne searcning criteria are codea in norma! PL/I code. 


The result of the search is an information tree containing the 
status of all found library entries, pius the status of tha 
parents, grandparent, aoe of each found tibrary entry uo to and 
incluaing status for the tibrary root containing tne founa entry. 
Tne tree represents the physical (as opposed to ftogical) liorary 
structure containing the founda library entries. Tne status 
information delineates each noce of the tree as a link, segment, 
Girectory, archive, archive components, MSFe or MSF components and 
includes enough other Status information to perform the 
appropriate tibrary maintenance function on founda entries without 
furtner information. | | 


Entry points are provided in tne tibd_descriptor_ subroutine to 
perform the type of searcning appropriate to tne particular 
library maintenance function pdeing performed. This maintenance 
function informstion is passeq to the library search program, 
which must tailor its seéearcning criteria according to fhe liorary 
maintenance function. 


General Library Maintenance Tools 


By using the tibrary cescriptor ana library search program, we 
nave not only centralized the tibrary organization into a single 
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mosules but have also enablea a subesystem maintainer to replace 
tTnis moauleé with one <aescribing nis Sub-system lioraries. He 
tnen nas a complete set of tibrary maintenance tools which will 
operafe on his sub-system tiborary in fTne same way aS on The 
Multics System Libraries. This generalization of the tJliorary 
tools beyond the Mulitics System Libraries is a pleasant sice 
effect of centralizing the library-dependent information. 


